home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19990422-19990725
/
000140_news@watsun.cc.columbia.edu _Fri Jun 11 09:55:38 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-07-23
|
6KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA23156
for <kermit.misc@watsun.cc.columbia.edu>; Fri, 11 Jun 1999 09:55:38 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id JAA02585
for kermit.misc@watsun.cc.columbia.edu; Fri, 11 Jun 1999 09:42:59 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: peter@baileynm.com (Peter da Silva)
Subject: Re: ISO VT320 emulator with key-bindings for Oracle Forms
Date: 11 Jun 1999 13:27:33 GMT
Organization: Bailey Network Management
Message-ID: <7jr2s5$4sc@web.nmti.com>
To: kermit.misc@watsun.cc.columbia.edu
In article <7johsh$egs$1@newsmaster.cc.columbia.edu>,
Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
>tputs() can be void or int. The third argument of tputs(), which is a pointer
>to a function to put a character, can be void, int, or char. The argument
>to that function can be void or char. Thus there are at least 2 x 3 x 2 = 12
>combinations that must be accounted for in any portable code that uses tputs().
Luckily you don't need to account for it by writing 12 versions of the code.
I normally encapsulate tputs itself into a routine (the name I usually use
is "outs"), and since C specifies that (char) promotes to (int) in fuction
call and return, that leaves you with two versions of the call to tputs
and two versions of the output function, in one place in the code.
>: > c. Dependent on buggy and/or incomplete databases;
>: That's something the end-user can fix.
>If the end-user knows how to. This is a rather obscure and dying art; one
>does not rely on end-users to have mastery of it. In these times, end-users
>expect software to "just work".
End users who aren't using ANSI X3.64 compatible terminals in 1999 are already
at the extreme end of the envelope.
>: > d. Offer only an incomplete and sketchy model of any real terminal,
>: > not even close to sufficient for defining an accurate emulation;
>: My vt100 emulator, which used raw termlib, did a better job of vt100
>: emulation than most commercial packages. It didn't try and provide
>: perfect visuals: double-wide and double-high letters, for example, were
>: simply not addressed. But it passed the vt100 torture test.
>Then it didn't run strictly from termcap/terminfo information; otherwise, it
>wouldn't have been a vt100 emulator, it would have been an emulator of every
>terminal that had an entry in the database, right?
No, it was a vt100 emulator that emulated the vt100 on every terminal in the
database.
> The database only encodes
>certain information about a terminal, not all the information needed to make
>a fully functional emulator. Such items as report requests and responses,
>forms-filling, and blockmode spring to mind.
Luckily I haven't ever had to deal with that on a vt100. Virtually all the
software I've ever run into that used block mode used it on a Televideo,
a Televideo-compatible, or a Uniscope.
But there's nothing inherently more difficult about dealing with block
mode than dealing with any of the other behaviour termcap doesn't specify.
>: > e. Notorious for refusing to work due to library version mismatches;
>: > f. Sometimes not available at all.
>: That's an easy fix. Same solution as B.
>It's easy if you understand cryptic messages about shared libraries, and
>are familiar with the politics regarding curses vs ncurses, libc vs glibc,
>competing numbering schemes, etc, and what to do about them.
I haven't run into that, but then I haven't writen code for Linux.
>: >And that in any case, this does not solve the original problem:
>: > How do I map Shift-Alt-F7 to such-and-such a function?
>: >The answer will still be: "you can't, because the software has no way of
>: >knowing that you pressed Shift-Alt-F7".
>: With a keyboard mapping file that maps escape sequences to symbols that
>: the user's interested in.
>If xmodmap recognizes your keyboard and can see Shift-Alt-F7 as distinct from
>other key combinations, then yes, but only for xterm. A separate solution is
>required for the console. Remote (non-X) sessions haven't a prayer.
Where did I say anything about xmodmap? I'm simply saying that a properly
written terminal emulator can run on UNIX and provide the functionality
required. That there isn't one that you know of is because there isn't a great
need for one, not that one's hard to write. As I said, I wrote one that ran
on Xenix-286, Solaris, and System V back in the late '80s. It was a port from
a DOS program I'd previously written, and I didn't find the porting
particularly difficult. Certainly dealing with termcap was a lot less hassle
than dealing with PC serial ports.
>It is hard to explain this to people who expect UNIX to be like Windows.
>While it might be possible to write a true terminal emulator for a specific
>UNIX variety on specific hardware that runs only in an X window (and in fact
>there are numerous examples -- xterm, Xfree86 xterm, the xterm versions from
>HP, IBM, and other companies that emulate their own proprietary terminal
>types), it is not possible in the general case, due to differences in hardware
>(e.g. different keyboards), windowing systems (in the X environment), screen
>drivers (in the console environment), APIs, and access methods.
That's just plain not true. Curses provides all the functionality you need
to write one that is portable to multiple UNIX systems and runs under multiple
terminal types. Yes, you do need to write your own keyboard mapping code, but
then you already have to do that to write a terminal emulator under Windows
that runs on internationalized versions.
I've done it myself, and there were several companies back in the '80s who had
commercial products that ran on a wide variety of UNIX platforms... I used
to have half a dozen boxes back in the computer room but they seem to have been
flushed in one of the spring cleanings. You can do as good a job of vt100
emulation on a UNIX system as you can on a PC.
--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
`-_-' Ar rug t� barr�g ar do mhact�re inniu?
'U` "Be vewy vewy quiet...I'm hunting Jedi." -- Darth Fudd